Developer CD Series 1999 October: Technology Seed

home *** CD-ROM | disk | FTP | other *** search

/ Developer CD Series 1999 October: Technology Seed / ADC Seed CD - October 1999.toast / FireWire / FireWire_2.0_SDK / Software / FireBug 1.0d7e10 / FireBug Readme 1.0d7e10 < prev

Wrap

Text File | 1999-04-12 | 30.6 KB | 637 lines | [TEXT/ttxt]

FireBug 1.0d7e10 readme FireWire is a trademark of Apple Computer, Inc., registered in the United States and other countries. FireBug is Apple Confidential and may be distributed only by Apple Computer. ** SUMMARY ** FireBug is a FireWire analyzer/snooper tool. Firebug examines the packets on a FireWire bus, and generates various real-time and post-mortem views of the data that is obtained. This includes running counts of tCodes, ack types, packet speeds, and so on, as well as formatted output of user-selected packets, such as quadlet reads or self-IDs. A variety of filters can be applied to the bus in order to select packets of interest for display. Unless certain optional commands (busreset, etc.) are used, FireBug is a passive entity on the FireWire bus. FireBug uses the snooping feature in the TI Lynx (revA and beyond) to receive all packets, regardless of the actual destination node. FireBug never sends acknowledgements to any packet. Other nodes on the FireWire bus will see FireBug as a dumb repeater, with an active PHY layer only. Due to hardware limitations, FireBug shows a "Link on" in its self ID, which may confuse other nodes. FireBug may be root, but does not act as cycle master, isochronous resource manager, or bus manager. FireBug is not a supported Apple product. ** CHARTER ** FireBug was developed to solve immediate debugging problems, not to be a good general-purpose FireWire analyzer right from the start. If you have ideas about what you'd like to see FireBug do, please let us know. ** INSTALLATION ** FireBug is an application, but it directly accesses the hardware in the Lynx card. Therefore FireBug cannot be used on a Mac running Blaze FireWire software. All FireWire software should be removed or disabled before FireBug is used. [Reboot after making such changes before running FireBug.] Because future version of MacOS should contain built-in FireWire support; it is possible that FireBug will not be usable on such systems. The MacOS versions known to work with FireBug are 7.6, 8.0, and 8.1. FireBug must process tens of thousands of snooped packets each second, so best performance will be obtained if all unnecessary Mac services are disabled. For example, disconnect all Ethernet or LocalTalk network cables, disable file sharing, TCP/IP, Control Strip, screen savers, and any background applications. Set your monitor to 256 colors or grays. Remove any CD-ROM discs. Nearly all extensions and most control panels can be disabled as well. In order to get maximum performance, FireBug deliberately does not participate in cooperative multi-tasking. Quit all applications before launching FireBug. FireBug seems to work correctly on these systems: 6360, 7200, 7600, 8500, G3. FireBug should work correctly on most PCI-based Mac running MacOS 7.6-8.1. FireBug requires 12100K of RAM, so a Mac with at least 16 megs is suggested. [Note, 7.6 can run in <4 megs if you remove most extensions, including OT.] If FireBug cannot locate a PCI-Lynx card in the Name Registry, it will not snoop. If FireBug finds a pre-revA Lynx, it will explain this, and refuse to snoop. Note: FireBug allocates about 9 megs from the system heap. This means you need about 12 megs free, total, even though Get Info says only 3 are needed. FireBug can snoop at least 16000 packets/second on a 6360/160 and a 7200/100, and at least 23200 packets/second on a 7600/200. However, FireBug cannot format this many packets per second for display. On a fast machine such as the PowerMac G3, FireBug can format 8000 cycle-start packets per second for display and add them to the scrolling list. But even on a fast machine, more complicated packets (such as isochronous data) may overload FireBug. ** ACCURACY ** FireBug relies on the PCI-Lynx card for its snooping. This card is connected to the CPU by the PCI bus. Therefore FireBug does not have the ability to do high-precision timing. However, FireBug can typically identify event times with sub-cycle accuracy (less than 125 microseconds). FireBug should be able to detect and report any error that causes the loss of a packet. Unless FireBug's DMA ring buffer wraps around completely, FireBug can compensate for falling behind by skipping packets. A message indicates that this has happened. By default, FireBug checks the header CRC on all packets, but not the data CRC. FireBug presently uses a 4096-packet DMA ring, but it will skip packets if it finds the ring is more than half full, in order to avoid wrapping the ring. If ring-wrap is avoided, the exact count of skipped packets is known. Therefore, any number of packets can be filtered for display, as long as no more than 2047 packets accumulate in the DMA ring at once. FireBug counts most values with unsigned 32-bit integers, so it can count at most 4 billion or so events before the counters overflow. When receiving several isochronous streams, this overflow could happen in a day or two. Don't trust the counters if you've left FireBug running overnight. [Snooping output should be accurate, however.] FireBug snoops up to 2048 bytes per packet, including headers, CRCs, and one or two quadlets for snoop information. This means that the largest asynch packet FireBug can actually snoop is about 1988 bytes. The largest isoch packet is probably about 2000 bytes. Packets larger than this will cause cryptic error messages. ** OUTPUT ** In general, hex values are displayed with zero-padding, while decimal values are not (except the running totals). Usually it should be obvious which is which, but FireBug could possibly be more consistent. Cycle timer and timestamp values are of the form seconds:cycles:offset, where seconds counts from 0 to 127, cycles counts from 0 to 7999, and offset counts from 0 to (I think) 3071. The Cycle timer in the upper left reads "CycleStart" and shows the most recently received cycle start packet, if there is a cycle master. It reads "CycleTimer" when the local clock is being used because no cycle starts are arriving. [This does not affect timestamping, which is always done with the local clock.] The NodeID, Root, and CPS values show FireBug's current Node ID on the FireWire bus, whether or not FireBug is root, and the value of the CPS (Cable Power Status) bit in the PHY. [Root does not (usually) indicate the node ID of the root node.] Running totals (tCodes, acks, etc.) show both the cumulative total, and the total for the last second. One second is defined in one of two ways. If we are receiving cycle start packets, then one second is measured by when the second field in those snooped packets increments. In this case, the cycSt counter should show exactly 8000 cycle start packets each second, and the isoch counter should be accurate (8000/second from the DV camera, 7200/second from the CCM camera, etc.) If we are not snooping cycle starts, then the local cycle timer will be used. However, its value is checked by software, not using the recorded timestamps, so one second may not be perfectly accurate. But, if there are no cycle start packets, perfect accuracy in measuring seconds may not matter. [I'll probably fix this to use the sampled timestamps as the local time base, which should improve the accuracy. For best results for now, make sure there is a cycle master if accuracy matters in the per-second fields.] If a node sends more than one Self-ID packet (because it has 4 or more ports), each will be shown, but only the first one will be decoded. Packets with all tCodes can be formatted for display. Payload of block packets (write block, read block respones, lock request/response, and isoch) can be displayed in Hex/ASCII dump. Bus reset timestamps are really the timestamp of the next received packet, which ought to be a self ID. [There is no way to measure the gap between the two yet.] Exception: If no packet is received immediately, the timestamp is instead determined by software, and is approximate. All output except the command history can be saved to a file with the "log" command. ** COMMANDS ** If a PCI-Lynx card is detected, FireBug will automatically start snooping, with a default set of generally useful filters activated. The commands documented below may be useful if you want to change the filtering parameters, or use other features of FireBug. To exit FireBug, press command-Q or hold down the mouse button. All commands are entered with the keyboard, similar to MacsBug, though some commands have command-key equivalents. FireBug has no menu bar. Holding down the mouse button should cause FireBug to quit even if it is too busy looking at packets to look at the keyboard. Some commands have command-key equivalents. These commands can be used at any time, even if another command is being entered with the keyboard. Processing of keystrokes is completely asynchronous, and a typed command is only parsed when enter or return is pressed. In particular, you can type in a command (such as tcode off) and then wait to press return until some critical moment, and, you can use command-key commands (such as busreset (command-R)) while you are waiting to press return. To repeat the last typed command, press command-return or command-enter. The remainder of this document lists the various commands supported by FireBug. ** FILTERS ** FireBug snoops all packets (even cycle-starts) from the FireWire bus. All of these packets are counted in the running totals of tCodes, speeds, etc. Only some of these packets will be shown in formatted output. When selecting filters, best results will be obtained by choosing filters that yield only a few hundred packets per second, or less. FireBug's filters are mostly subtractive. This means that a packet must satisfy every filter in order to be shown in the formatted output. The general assumption is that you are looking for one particular packet of interest, not several kinds of packets. For example, if you filter for tCode 1 (Write block) and ACK 1 (complete), you will see only block write packets for which the target node responded with an ack_complete. You will not see any other packets that caused ack_complete, and you will not see any other block write packets. There is a master filter that controls all non-error output. To toggle this filter, press command-F. To turn off the master filter whether it is already off or not, press Escape. To turn on the master filter if you don't know its current state, press Escape, then command-F. Both Escape and command-F can be used if you have already typed in part of another command, and they will not interfere with what you have typed. The filters currently implemented are: tCode, ack, short. The tCode and ack filters operate as follows: Any or all of the filter values may be selected. For example, the tCode filter can be set to match tCodes 4, 6, 9, and b (quadlet read, quadlet response, lock request, and lock response). The filter can also be set to match all tCodes, in which case the filter has no effect, or to match no tCodes, in which case the filter removes all packets except PHY packets (which do not have any tCode). The following commands are used to set the tCode filter: > tcode on // match all tCodes (disables filter) > tcode off // match no tCodes (no async or isoch packets) > tcode 4 6 9 b // show only quadlet read/response & lock req/resp > tcode 469b // (same as above) > tcode on 469 b // add tCodes 4, 6, 9, and b to the current filter > tcode off 4 6-b // remove tCodes 4, 6, 7, 8, 9, a, and b > tcode // show current filter settings The "short" filter will show block packets only if they are shorter than their header says they should be: > short on The window command can be used to display a fixed number of packets before and after any packet that passes the filter. For example, you could filter on ack 4 (busyX) and d (data error) and set the window to show the previous and next 2 packets. The previous packets might have interesting timestamps (say, unusually close together), and the following packets might show retries. This command has three forms: [Note, command is xwindow until I clean it up] > xwindow 3 10 // show 3 packets before and 10 after any filtered packet > xwindow 5 // show 5 packets before and after any filtered packet > xwindow // show current window setting The window command acts as an override, showing some packets that might not have been seen. The extra packets are still subject to filtering, meaning that if they also pass a filter, they will cause yet more window packets to be shown. However, packets that fall in multiple windows are not shown multiple times. The window command does not quite correctly handle previous packets yet, in three ways. First, if the pre-packet window includes bus resets, they will be shown out of order (they will preceed the windowed packets). The timestamps may be helpful in finding the true order of events. Also, pre-packet window packets will display incorrect ack codes and true packet lengths, and may have incorrect length payload dumps. [Payload lengths from headers should be correct. Try a pre-packet window on isochronous packets to see the problem clearly.] Finally, pre-window packets will include cycle starts, because the last N non-cycle-start packets could have been so long ago that the buffer has already been recycled. [However, I hope to improve this by using a secondary window buffer]. To disable windowing, use the command "window 0". The maximum pre- and post-packet window sizes are 99 and 500. Note that windowing shows all packets, even cycle starts, during the pre-window period, but only all packets except cycle starts during the post-window period. The cyclestart command is related to the window command, and controls how many cycle start packets are shown after a filtered packet. This is different from the window command, which selects how many non-cycle-start packets are shown after a filtered packet. The cyclestart command also has two forms: > cyclestart 2 // show 2 cycle starts after any filtered packet > cyclestart // report current setting There is a special filter for looking for missing isochronous packets: [Note, command is xisogap until I clean it up] > xisogap 62 This filter (technically) matches a cycle start packet that follows a missing isochronous packet. The filter works as follows: When a cycle start packet is received, the filter is "armed". When isochronous channel 62 is received, the filter is "disarmed". If another cycle start packet arrives when the filter is "armed", this triggers the filter, because two cycle starts arrived without a channel 62 packet between them. The filter will not operate again until a channel 62 packet arrives (otherwise, it would fire forever once channel 62 shut down). You probably want to use "isogap" together with the "window" option in order to see the real isochronous packets before and after the missing packet, so that you can examine the payloads or timestamps or whatever. You can disable this filter by setting it to an illegal channel number (eg 64). When used with an isochronous source such as the CCM camera, that only transmits on 7200 out of every 8000 cycles, the filter will be triggered fairly often. Only one isochronous channel can be monitored for gaps with this filter. There is a special filter for displaying a burst of isochronous packets: > isosnap 20 This filter causes the next 20 (or any number specified) isochronous packets to be displayed, regardless of the other filters. This filter turns itself off after the "snapshot" is complete, or it can be cleared by setting it to zero. ** OPTIONS ** FireBug attempts to record a timestamp for each snooped packet or bus reset event. Because of the nature of Lynx and the PCLs used to control it, the recorded timestamps indicate a time shortly after a packet was completely transferred into Mac memory. This time differs from the actual packet arrival time for two main reasons. First, Lynx contains a FIFO that buffers received packets in order to compensate for PCI access latencies. After a packet finishes arriving from the bus, the packet will not finish arriving in Mac memory until the FIFO has drained. This delays the capture of the timestamp. The second reason for delay is the operational speed of the PCL engine in Lynx. Once the packet has been placed in memory, Lynx (like a CPU) must fetch its next instruction. The next instruction after each packet reception is to sample the local cycle timer and record the value in memory. This operation requires several PCI accesses, so it consumes more time. [Note that once the cycle timer value has been sampled, the additional delay of the accesses required to store that sample in memory will not affect the timestamp value. In specific Lynx terms, the PCL operations are RCV to snoop a packet, followed by LOAD to copy the cycle timer to the Lynx temporary register, and finally STORE_QUAD to record the cycle timer in host memory along with the snooped packet.] Timestamps are based on the local cycle timer, which is not synchronized to the received cycle start packets. There could be some drift. [This may change.] Timestamp display is optional, and can be controlled with these two commands: > timestamp on > timestamp off Presently, disabling timestamps does not cause a change to optimize the Lynx PCLs. The timestamps are still recorded by the DMA, they just aren't shown to you. This leads to a small performance improvement, because less information is being drawn on the screen, but the DMA performance does not change. FireBug can display a hex dump of packet payloads. Packets with tCodes of 1 (block write), 7 (read block response), 9 (lock request), A (isochronous), and B (lock response) have variable-length payloads. To specify the number of quadlets of payload to be dumped, use the data command: > data 8 The above command causes (up to) 8 quadlets of payload to be displayed for all of the above packets (when they pass all active filters). The actual number of quadlets shown will depend on the true length of each received packet. To see the entire contents of such packets, use an impossibly large quadlet count, such as 1025. To disable payload dumping, specify 0 quadlets. The default value is 0. Note that displaying payload contents takes a while, and will reduce the maximum rate at which packets can be displayed. Select the lowest number of quadlets possible to get best performance. Payloads that are not an exacty number of quadlets are zero-padded in 1394. The snooped packets should show this zero padding. ** HISTORY ** FireBug presently stores 20479 lines of snooped packet history. You can scroll back through this history using the up/down arrow keys, the page up/down keys, and the home/end keys. Any new activity will cause the history to snap back to the bottom. The key repeat rate for a key that is held down can be set with the Keyboard control panel. Holding an arrow key down for a while will also cause FireBug to scroll faster (up to triple-speed). The history consists of 20479 lines of text, not (usually) the last 20479 packets on the bus. There is no way to apply or change filters after the fact. You can save part or all of the history to a file, together with the latest cumulative statistics. Use the "log" command, with an optional count of the number of lines to write out. This command writes the last 1000 lines of history, plus statistics, to a file: > log 1000 With no argument, "log" writes the entire history buffer. ** OTHER ** > map pciName <count> The map command tells FireBug to try to use a particular Lynx chip by mapping its registers. Because FireBug searches for Lynx using TI's vendor ID and device ID, most users will not need this command. If you have multiple Lynx interfaces with the same PCI name, you can add a count argument to map to indicate which one you want. (This may not work.) Warning: The map command looks up the name you give it in the Name Registry, then attempts to map the first matching entity into memory. FireBug will then try to activate snooping. If the thing you map is not a Lynx chip, FireBug can wreak havoc on your system by writing meaningless data to hardware. Be careful! Don't even think about using "map" on another kind of 1394 interface, such as OpenHCI or Pele. This won't work at all, and may screw up your Mac. Map with no arguments will stop FireBug. You can use the map command even if FireBug is already snooping, to switch to another chip. > busreset (Command-R) The busreset command will cause FireBug to initiate a reset of the FireWire bus by writing the IBR bit of PHY register 1. In the rare event that FireBug detects a bus reset or other interrupt while it is attempting to trigger a reset, it will abort its attempt. You can hold down Command-R to fire off large quantities of bus resets. This can be a useful way to test the robustness of your software, without wearing out connectors. > sync (Command-S) FireBug will suspend snooping for a brief period (typically less than a millisecond) so that the Lynx cycle timer can be updated with an incoming cycle start packet. This allows timestamps to reflect the "real time" on the bus. It is interesting to snoop cycle start packets after performing a sync; one can watch the Lynx clock drift out of sync with the cycle master. Examining the timestamps of snooped cycle starts also yields some insights as to the accuracy of the timestamp mechanism. Using the sync command will cause some packets to be missed (at least one cycle start, and any other packets arriving during the sync time). Examining the per-second counts may give some indication of the impact of the sync. After the local cycle timer has been updated, FireBug will display one cycle start packet in the packet output, regardless of filter settings. At present, this is a cycle start taken somewhat randomly. [I hope to change this so that the very first cycle start after the sync will be shown instead.] Because the sync command must disable the snoop function, Lynx sometimes picks up a garbage packet as a result. I think this is a hardware "feature". If using sync during isoch or heavy async traffic, watch for unusual/illegal packets. > zero (Command-Z) All cumulative-total counts will be zeroed. Filters and other operations are not affected. > clear (Command-K) The scrolling window of snooped text will be cleared. > bread address length This command sends a block-read request packet on the bus. The outbound packet will not be shown in the snoop history, but the response (if any) will be shown - if it passes the active filters. You can use this command to read the CSR of a remote node, or any other address. Note that if an error is reported, the ack that is reported may not be meaningful. Typical usage of the bread command is: > bread ffc0fffff000040c 8 This sends a block read request to node 0 for CSR ROM address 40C of length 8. The returned data (if the target supports block reads) will be the 8-byte unique ID of node 0. You can specify length 4, and FireBug will still send a block read (not a quadlet read). Technically, it should probably use a quadlet read instead. However, FSL, the Sony DV camera, and the Sony CCM camera are all willing to respond to block reads of length 4. Be sure to enable the correct filters so that you can see the response. ("tcode on 67", "ack all" and "data 4" (or more)). > qread address This command works just like bread, except that it sends tCode 4 (quadlet read request) and you don't specify a length. Some devices won't respond to block reads in their CSR, even of length 4, but will respond to quadlet reads. Example: > qread ffc1fffff000040c Note that FireBug does not acknowledge the response to a bread or qread command, and this can confuse the other node. FireBug can read and write PHY registers using these commands: > phyread 0 > phywrite 1 40 Register numbers are decimal arguments (0-15), the write data is given in hex. The above example reads register 0, then forces a bus reset. Use with caution. FireBug can send PHY configuration packets using these self-explanatory commands that take one hex argument each: > phyconfig 00ff0000 // Raw packet (force root 0, gap count 3f) > gap 3f // Set gap count 0x3f only > root 4 // Set force_root 0x4 only > linkon 1c // Send link-on to node 0x1c FireBug can read and manipulate the Lynx GPIO pins using these commands: > gpio // Show current values only > gpio 0 on // Set GPIO 0 to output a one > gpio 3 off // Set GPIO 3 to output a zero > gpio 2 z // Put GPIO 2 in tristate On the Apple FireWire DV card, "gpio 0 on" sets the contender bit. FireBug places all four GPIOs in tristate when it starts up. Only one GPIO can be manipulated per command. The state shown does not indicate whether FireBug is driving the state, or sampling it (tri-state) [You are supposed to remember how you set them]. DANGER: Make sure you know what the GPIOs do on your particular hardware before you use this command. These commands can turn off (or on) the hardware sampling of one timestamp and one interrupt set per packet: > sampletime off > sampleints off When timestamp sampling is off, timestamps are not shown. When interrupt sampling is off, interrupts (notably, bus reset) are not shown. Bus resets can be inferred from the presence of self-ID packets. Turning off both options will eliminate a lot of DMA/PCI overhead. The snoop command can turn off snooping. When snooping is off, Lynx will receive only packets sent to it, rather than receiving all packets. Lynx will still receive all isoch packets. Asynch packets sent to Lynx will be acknowledged with ack_pending or an error ack. FireBug will not see cycle start packets when snooping is off, but the cycle timer will be updated if cycle start packets arrive. > snoop off Two utility commands are provided that have nothing to do with the card (if any) FireBug is using: The first command performs a CRC on seven bytes, as used in the serial EEPROM on Lynx. Exactly seven bytes of hex data must be entered as shown here, with leading zeroes, and with one space between. For example, these values from the TSBKPCI card give the answer 0x70: > lynxCRC 04 03 02 4c 10 03 80 The other utility command computes 1394-style Bus Info Block checksums. Exactly four quadlets of hex data, each eight characters long, must be entered. One space is used between each value. (Type carefully!) The CRC is computed, and the resulting five-quadlet Bus Info Block is displayed. For example: > romCRC 31333934 f0647000 08002851 000009de ** DEFAULTS ** FireBug's default configuration is essentially what would result from these commands: > zero > clear > tcode 0-7 9 b-f > ack on > data 0 > window 0 > cyclestart 0 > timestamp on > snoop on > sampleints on > sampletime on > short off ==================================================================================== Version history 97.02.03 * First internal distribution. 97.02.10 * Fixed payload size displayed for block write packet (forgot to >> 16). * Added "map" command to allow use with 3rd party Lynx cards. * The check for missed interrupts was made tighter. Warnings should be more rare now. 97.02.12 * Added "data" command to dump payloads. 97.02.25 1.0d1 * Fixed payload dump for payloads with zero-padding. * Fixed tCode 7 (block response) payload display. * Added "bread" command to send block read requests. 1.0d2 * Added tCodes 1, 5, and 7 to default settings. * Lock request/response packets, if shown, always dump at least 4 quads of payload. * Now look for both pci104c,8003 and pci403,605 automatically at startup. * Added "qread" command to send quadlet read requests. * Added "clear" command to clear scrolling snoop history. * Added master filter (Command-F and Escape key). * Added "window" and "cyclestart" commands, though they still need work. * Now check keystrokes more often when swamped with packets. * Added "isogap" command to look for missing isochronous packets. 97.11.03 1.0d3e1 * Not sure of the distribution for 1.0d2, renumbered to be safe. * Added "isosnap" command. * Renamed "window" to "xwindow" and "isogap" to "xisogap" until they're cleaner. 98.02.08 1.0d3e2 * Added lynxCRC and ROMCRC commands to compute EEPROM CRC values. 98.03.12 1.0d4e1 (Clinton Bauder) * Look for pci106b,1a Lynx cards. * Support Self-ID packets for PHYs with >3 ports. * Build with CodeWarrior 11. 98.03.29 1.0d4e2 * Added auto-detect of any Lynx card. * Added save-to-file ("log"). * Added last command repeat (press command-enter or command-return). * Sources now include both CW9 and CW11 project files. * Added resource file with version string. 98.05? 1.0d4e3 * Clinton added some 1394a PHY support. 98.05? 1.0d4e4 * Unknown changes (none?) 98.06.22 1.0d5e1 * Added support for VM and ROM-in-RAM / New World. * Added phyread and phywrite commands. * Added Command-K shortcut for "clear" command. 98.07.07 1.0d5e2 * Fixed bug in Bus Reset to make more reliable (fewer "interrupted" errors). 98.07.25 1.0d5 * Version for distribution with FireWire 1.1 SDK. * Fixed negative actual packet sizes in block read/write packets * Removed write to PHY register 0xD during setup (this fixed an early prototype PHY but makes current versions fail). Use "phywrite" instead. 98.08.01 1.0d6 * Real version for distribution with FireWire 1.1 SDK. * Show speed code on all snooped packets (except PHY packets): s100, s200, or s400. * Detect missing self-ID packets ("m" bit set, followed by bit 23 clear). * Added phyconfig, gap, root, and linkon commands to send PHY packets. * Added gpio command to read and control Lynx GPIO pins. 99.??.?? 1.0d7 * No longer set Posted Writes or enable Slave Bursts - Lynx rev A says not to. * Added short command to show only short block packets. * Count short block packets [and any non-4n packet!] as DMA errors. * New index argument for map command (e.g. "map pci104c,8003 2" for second card). * No longer clear PCI Write Invalidate Enable bit on startup. * New sampletime and sampleints commands. * Can map another Lynx chip while running. * Added snoop command to disable snoop. * Report more information about chip we use. * Added SBP-2 decode feature. "sbp off" to disable it. Accurate until a bus reset. * Now show any non-zero rCode on snooped packets. * Can put a comment in the log text by preceeding it with *. Enter only * for a line of *s. * Show tLabel for write req/resp. Show rCode in write response. ==================================================================================== FireBug software and documentation (mostly) by Eric Anderson, ewa@apple.com Copyright 1997-1999, Apple Computer, Inc.